\subsection{Lexer}
El análisis léxico no se trató de una traducción literal de la especificación provista en la consigna. Esto se debe a que
agrupar distintas keywords, comparadores y operadores dentro de un mismo token hubiese forzado a incluir dentro del parser
código adicional para distinguir de cuál se trataba.

A nuestro criterio, este era trabajo del analizador léxico, por lo cuál se definió una cantidad mayor de tokens para simplificar el trabajo posterior.

\subsection{Conflicto en parseo de cláusulas if}
El parser es generado a partir de una gramática que describe el lenguaje Jay. La siguiente regla nos trajo problemas a la hora de reconocer cláusulas \texttt{if}:
\begin{equation}
	\texttt{ifStatement} \rightarrow \textbf{if}\ (Expression)\ stmt\ \|\ \textbf{if}\ (Expression)\ stmt\ \textbf{else}\ stmt
\end{equation}

Se decidió transformarla a la siguiente:

\begin{equation}
	\texttt{ifStatement} \rightarrow \textbf{if}\ (Expression)\ stmt\ elseCase\\
\end{equation}
\begin{equation}
	\texttt{elseCase} \rightarrow \lambda\ \|\ \textbf{else}\ stmt\\
\end{equation}

Al generar el parser de esta forma, \textbf{bison} informaba de un conflicto de tipo \textit{shift/reduce}. Un caso que ilustra este conflicto es la siguiente cadena:

\begin{center}
if (a) if (b) c = 1 else c = 2;
\end{center}

Notar que justo antes de leer el token \texttt{else}, el parser no sabe si reducir el \texttt{ifStatement} o seguir procesando. Como lo que se quería es asociar cada \texttt{else} con su \texttt{if} más cercano, se aceptó el comportamiento por defecto de \textbf{bison}, que consta en desplazar siempre que pueda.

\subsection{Construcción del HTML}
El HTML de salida se fue construyendo a medida que se parseaba la entrada, utilizando las \textit{acciones semánticas} de \textit{bison}. Lo que se está haciendo, en efecto, es una traducción dirigida por sintáxis, donde a medida que reconocemos la estructura del código de entrada escribimos un archivo html de salida.

Para mantener separado el código de escritura del archivo del parser, se creó una clase denominada \texttt{HTMLWriter}, que provee una interfaz declarativa para ir construyendo la salida.

Se instancia globalmente una variable en el código del parser a generar, y a medida que se reconoce la estructura de la entrada se va llamando al \texttt{HTMLWriter} dentro de las reglas semánticas.


\subsection{El manejo de errores} 
En caso de que la entrada no se corresponda con un fuente Jay, el parser debe informarlo. Si bien había varias maneras
de hacerlo, optamos por una de las más sensillas aprovechando las funcionalidades de las herramientas usadas.

Agregando la directiva \texttt{$\%$ error-verbose} en las declaraciones del \textbf{parser}, bison agregara al
reporte de error tanto la línea como el token que generó el error (y lo que se esperaba leer). Para mostrar esto
definimos la función \texttt{yyerror} para que opere de la siguient1e forma:

\begin{verbatim}
 int yyerror(const char *p) {
  cerr << "Error en linea " << yylineno 
       << " leyendo: \"" << yytext << "\"" << endl; 
  cerr << p << endl; 
}
\end{verbatim}

